Field of the Invention
The present invention is related to the area of computer-facilitated communications over networks, and more particularly related to a method, a system and infrastructure for managing and serving certificates for service or platform providers to provide secured communications over a data network (e.g., the Internet).
Description of the Related Art
SSL (Secure Sockets Layer) is a standard security technology for establishing an encrypted link between a web server and a browser (e.g., IE from Microsoft or Chrome from Google). This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites to protect their online transactions with their customers.
To create such an SSL connection, a web server requires an SSL certificate. When an entity chooses to activate SSL on its web server, the entity or an operator thereof has to complete a number of questions about the website and the entity. With a valid SSL certificate, the web server will then be able to establish an encrypted link between the website and a web browser accessing the website.
Such an encrypted link is initiated, established and maintained by HTTPS (HTTP over SSL) which is a protocol for secure communications over a computer network. HTTPS widely used on the Internet consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security, or its predecessor SSL. The main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data. In its popular deployment on the internet, HTTPS provides authentication of the website and associated web server with which one is communicating and further protects against man-in-the-middle attacks. Additionally, it provides bidirectional encryption of communications between a client and a server, which protects against eavesdropping and tampering with or forging the contents of the communication. In practice, this provides a reasonable guarantee that one is communicating with precisely the website that one intended to communicate with (as opposed to an impostor), as well as ensuring that the contents of communications between the user and site cannot be read or forged by any third party.
Traditionally, each IP address serves one SSL certificate. This would be a problem when one IP address serves many virtual sites, such as in the case for a multi-tenant SaaS or hosting provider, each user or tenant designating a different domain name thus requiring a different certificate. As an example, FIG. 1A shows a display 100 of a browser accessing an exemplary online store or website, www.shopemmajoy.com. As shown by the notation 102, it is a secured website indicated by https://. In other words, communication between the browser and the website is secured. In addition, a user (i.e., a customer) operating the browser is ensured that he/she is accessing an authenticated website operated by shopemmajoy, all of which is guaranteed by the underlying SSL certificate from the server.
It is assumed that the customer shopping on the website proceeds with checking out some chosen items. FIG. 1B shows a display 110 of the browser accessing another website (https://checkout.shopify.com . . . ). The sudden change of the website, especially at the moment of conducting a financial transaction, could potentially cause the customer to pause the transaction, if the customer is savvy enough to understand the consequence of going to another website to pay for something chosen at a different website, shopify.com.
In reality, there is nothing wrong with the redirection of the shopping website to a checkout page at another website. The operator of the checkout website, Shopify in this case, is a service provider in the business of facilitating retail point-of-sale transactions for online stores. Many online stores sign up with Shopify to let the service provider take care of various transactions. In other words, Shopify would need to manage at least one certificate for each of its customers. As more businesses sign up with Shopify, the cost and complexity of managing a growing number of certificates are going up.
From a business perspective, it may be operationally acceptable for a large corporation, such as Shopify, to manage certificates for millions of its customers. However, for a small business, it would be a forbidden operation to manage a large number of certificates for its hosted websites individually designated by many of its customers. Many multi-tenant applications or platform providers (a.k.a., platform or service provider) wish to provide their users with custom-designated domains that reside behind SSL (HTTPS). For example, a blog-base provider (e.g., www.exampleblog.com) wishes to allow each of its users to have their own designated hostnames (e.g., johnsmith.exampleblog.com or site4mary.blogmedium.com). As more users sign up with the provider, there are more certificates. The cost and complexity of managing these secured websites with at least one certificate for each of the users can easily go beyond what the provider could do operationally. Thus, there is a need for techniques that can help these providers, small or large, manage as many users as possible without incurring the cost and complexity of managing the certificates.
In operation, a platform provider traditionally needs to store at least a certificate and a certificate key in a database record associated with a domain name. When a request for accessing a hosted website comes in, the platform provider has to serve a corresponding certificate based on the matched domain name (e.g., a requested hostname). This becomes a problem when the platform provider needs to serve a large number of customers. Each certificate has a different expiration date. It would be a huge burden for a service provider, especially as a small to medium business, to manage renewals of a larger number of certificates. Allowing a certificate to lapse and expire could be a big issue for platform providers and their customers. Thus, there is another need for techniques that can help these providers manage as many users as possible without concerning the renewals of the certificates for their increasing customers.
For smaller platforms that want to serve dynamic customer domains with SSL, this can be costly to manage. Larger companies, such as Shopify, have the resources to provide their own IT infrastructure, but smaller platforms specialized in serving content specific to an application platform do not want to invest in infrastructure to deal with the handling of a large number of customer certificates. Thus, there is yet another need for techniques that can help these providers with necessary infrastructure to manage the certificates of their customers transparently.
There are more needs that will become apparent upon examining the following detailed description of the present invention.